Repository navigation
Precompile show, \, products, broadcast, concatenation and sprand of sparse Float64 arrays - #1103
ViralBShah wants to merge 4 commits into
Conversation
…se Float64 arrays Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@KristofferC Is it ok to include this in an stdlib (which is not in the system image)? |
TTFX: 2 robust regressions, 5 robust improvements.
DetailsJulia 1.15.0-DEV.167 · Linux X64 · 4 blocks (ABBA)
Dependents (median change over blocks)
Dependents per block
A change is robust when every block clears the threshold (precompile 8%, load (cold) 10%, run (cold) 15%, load+run (warm) 15%), the samples of the two commits do not overlap, and the medians differ by at least the floor (precompile 0.25 s, load (cold) 0.1 s, run (cold) 0.05 s, load+run (warm) 0.05 s). Load and run are also judged with the GC off, and either counts. Over all packages whose base value is at least the floor, each metric's geometric mean must clear a threshold in every block (precompile 2%, load (cold) 2%, run (cold) 3%, load+run (warm) 3%). |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1103 +/- ##
==========================================
+ Coverage 94.66% 94.68% +0.02%
==========================================
Files 16 16
Lines 10437 10441 +4
==========================================
+ Hits 9880 9886 +6
+ Misses 557 555 -2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@IanButterworth Seems like TTFX is doing its job here. Pinging for you to take a look since I thought you may find it useful to see it in action. |
|
Just in case this was closed because of the precompile time, that doesn't matter for stdlibs. I'd consider this a win for run time? |
|
The load time might be worth reevaluating on latest nightly. |
|
I just closed it because the small savings in TTFX didn't seem to be justified by the larger system image size. Do you think this is a good tradeoff? Good point to test it out on the latest nightly. |
|
Yeah I don't see any negatives here. Stdlibs come precompiled so cost during build isn't bad to the user. The rest is positive. |
|
Worth adding the |
To make sure I understand, is this correct: when this PR is included in the bump upstream, the |
|
Yeah. |
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
show, \, products, broadcast and concatenation of sparse Float64 arraysshow, \, products, broadcast, concatenation and sprand of sparse Float64 arrays
SparseArrays is not in the sysimage, and its package image holds almost no native code (a 56 KB
.so), so the first call of every common operation compiles:showof a matrix takes about 0.4 s andA\babout 0.6 s.Before (
main), first calls in a fresh session, Float64SparseMatrixCSCwithIntindices:.ji+.soshowA\bA*xmainAfter:
.ji+.soshowA\bA*xsrc/precompile.jlruns the common operations on small Float64 literals behindBase.generating_output(), the pattern Profile and Pkg use, so their native code goes into the package image; nothing runs at load. The solver calls are behindBase.USE_GPL_LIBS.sprandis included because the TTFX check's workload,S = sprand(200, 200, 0.05); kron(S, S); S * rand(200), calls it. With it, the first run of that workload compiles onlyrand(::Int)and takes 19.6 ms instead of 305.6 ms (median of 12, Julia 1.15.0-DEV.142, macOS arm64).The cost is 25 ms of load time (17.4 → 26.0 ms in the same measurement), a package image about 7 MB larger, and about 4 s more to build it, which Julia's build and download carry too. A profile of the load splits the extra time about evenly. One half is reading the larger image (the
.jigrows from 8.1 to 13.8 MB). The other half is checking each cached method's calls into Base and LinearAlgebra against the current method tables, whichmain's image needs almost none of. Loading the native code costs little. Left out:ComplexF64, which would take load to 229 ms and the image to 16 MB + 2.7 MB.🤖 Generated with Claude Code